The Internet has fulfilled much of its early promise of enabling a single computer to service the requests of many millions of geographically dispersed users. In consequence, however, the Internet has introduced security concerns of a new magnitude, making a single computer potentially vulnerable to attack from many millions of sources. Even if a server is effectively protected against intrusive security breaches, it may still be vulnerable to a range of denial-of-service attacks, such as connection depletion attacks. A connection depletion attack is one in which the adversary seeks to initiate, induce server commitment for, and leave unresolved, a large number of connection (or service) requests to a server, possibly exhausting the server's resources and rendering it incapable of servicing legitimate requests. Inducing a server to erroneously commit to a large number of connections can prevent the server from establishing legitimate connections.
TCP SYN flooding is an example of such an attack. Other connection depletion attacks in this same genre include so-called “e-mail bomb” attacks, in which many thousands of e-mail deliveries are directed at a single server target, as well as attacks mounted using high volume read or write traffic via FTP connections with the aim of saturating server storage space or communications bandwidth. Also potentially vulnerable to connection depletion is the SSL (Secure Socket Layer) protocol.
The TCP SYN flooding attack serves as a good example to illustrate some of the issues surrounding connection depletion attacks, as well as some of the proposed defenses. The TCP SYN flooding attack aims to exploit a weakness in the TCP connection establishment protocol whereby a connection may be left “half-open” by the connection-requesting client. The protocol normally proceeds as a three-way handshake. A client requesting a TCP connection with a server begins by sending the server a SYN message. The server commits to establishing the connection by replying to the client by sending a SYN-ACK message, and then prepares the connection by allocating buffer space and initializing any other software required to support the connection. The client completes the protocol by responding with an ACK message. At this point, the connection is established, and service-specific data can be exchanged between client and server.
To mount a TCP SYN flooding attack, the adversary initiates, by soliciting and receiving server commitment to, a large number of connections and then leaves them uncompleted. In other words, the adversary repeatedly fails to send the final ACK message that completes a connection. In essence, the attacking client solicits server commitment without itself ever committing to the completion of a connection. Since the server allocates buffer space when committing to each incomplete connection, the adversary can exhaust server memory designated for TCP requests, thereby causing the server to deny legitimate connection requests.
A number of mechanisms have been proposed to defend against TCP SYN attacks. Most of these are based on one of three different approaches: time-out, random dropping, or “syncookies.” The time-out approach discards a half-opened TCP connection after a short period of time if the ACK packet from the client has not been received. While easy to implement in existing TCP servers, this approach can be defeated by an adversary who sends the SYN packets at a rate fast enough to fill the connection buffer. Moreover, a short time-out may be problematic for legitimate users whose network connections have long latency.
In the random dropping approach, half-open connections are discarded at random when the connection buffer reaches a certain percentage of its capacity. This prevents a complete denial of service for all legitimate clients as a group, since the server buffer is never completely full. On the other hand, some legitimate connections are as likely to be discarded as those of an adversary, so substantial degradation in service to legitimate clients may result. This is particularly the case when the adversary is capable of sending service requests at a substantially higher rate than legitimate users, as is possible in such environments as an internal network.
One defense against TCP SYN flooding uses so-called “syncookies.” In the syncookie approach, for each client request i, the server sets the sequence number in its SYN/ACK message to a value Vi calculated by hashing various connection parameters with a secret value known only to the server. Only upon receiving an ACK containing Vi from the client making request i does the server allocate resources for the connection. The primary limitation of the syncookie approach is its assumption that an adversary performing IP spoofing will not receive the SYN/ACK message sent to the spoofed address, and therefore will not be able to provide the server with the value Vi. This assumption is not always correct, particularly in an internal network, such as an Ethernet, in which intercepting packets is relatively easy. The ISAKMP key management protocol, used in the IETF's IP Security standard, provides for the use of syncookies to defend against TCP SYN attacks.